Over the past few years, online banking and commerce have become increasingly important and widespread. Typically, such activities are conducted over networks, such as the Internet, and comprise transaction communications between the users of browser computers and server computers associated with databases. For example, users may be customers of a financial institution, such as a bank or a brokerage firm, which stores customer account information in a database. Increasingly, such information is made available to the customers for online transactions, such as balance inquiries and fund transfers. During off-peak hours, a single customer may easily access the appropriate database. From time-to-time, however, market forces will cause multiple customers to simultaneously seek online transactions. At such times, long delays in customer log-in and transaction requests may be encountered.
Such delays are due to two complications. The first complication is simply the high volume of requests received by the server during such periods. In order to process the requests in an orderly fashion, the server holds the requests in a first-in-first-out request queue. Once a request is serviced, the server proceeds to the next request. This technique produces long queues when numerous requests are received by the server. The second complication is the stateless nature of the Web environment and the HTTP protocol. Since the protocol is stateless, each request from a client requires a new connection to the server. Because most customer sessions include multiple requests and responses, high-volume periods further delay the progress of each session.
For example, a customer may request to (1) log-in, (2) receive a balance statement, (3) transfer funds, and (4) initiate a trade. This session requires at least four client requests and server responses. During high-volume periods, the stateless nature of the HTTP protocol requires each of the four requests to compete with all other requests to log-in or transact. In other words, even after a log-in has been established by request (1), requests (2)-(4) are placed at the end of the queue and do not receive priority over log-in requests from other customers. In contrast, if the same session were performed via a telephone call, all requests and responses subsequent to the initial dial-in request (which is functionally analogous to a computer log-in request) are passed over a dedicated phone line without interruption or delay from other customers trying to dial in.
As a result, each web-based request for an interaction, including requests for quotes, balances, trades, etc., must compete with the log-in attempts and requests of others. Furthermore, as a transaction or log-in request is delayed by others, the requesting software may time out and indicate to the customer that the request should be made again, or the customer may decide to abort the current request and initiate a retry. In either case, the load on the server system increases. In contrast, a customer who attempts to make a phone call to an institution whose phone connections are currently in use will receive a status message in the form of a busy signal. Typically, the customer will then hang up and try again after a period of time has lapsed. Significantly, transactions occurring on dedicated phone lines are not interrupted or delayed as they may be in web-based transactions.
Thus, if each server log-in request were required to wait until current transactions are complete, and if each customer with a waiting request were notified of the status of the request, transaction delays and repeated requests would be diminished and largely eliminated